Computer-based workflow control systems are used in a variety of scenarios where work items are processed at different processing stages. Generally, for representing the work item, for example a concrete, physical object such as a piece of equipment or a document, or an abstract object such as an electronic representation of a document, a data object is created and stored as a data structure in a database. For processing the work item, the workflow control system controls the transitions of the work item and/or the respective data object between the different processing stages, associating a different workflow state with the data object at each processing stage. Typically, the workflow control system controls what actions are permitted and/or must be performed at each processing stage. Particularly, if the work item is the data object, the workflow control system controls what actions on the data object are permitted and/or must be performed by an application process. Application processes performing actions on the data object may be fully automated or controlled by a user. The actions on an object that a user is permitted to perform through an application process are determined by specific roles or profiles associated with the user. Each workflow state has a user role assigned. During processing of a data object, the workflow control system creates a workflow instance for the data object wherein a specific user (reference) is assigned to each possible workflow state of the workflow instance. If the role or profile of a previous user changes, the workflow control system must assign a new user to pending workflow states to which the previous user was assigned. The workflow control system notifies a user assigned to the current workflow state of a data object. Systems that are based on such conventional workflow control systems show limitations in team-based (collaborative) data processing and in data processing systems where unique locating references are used to reference the data objects, for example a URL (Uniform Resource Locator) for direct access to the data object by a conventional browser. Particularly, in the conventional systems, references to data objects are used in such a way that a specific action on a data object is linked tightly to the time of the request of the action but not to the time the action is actually performed. Thus, in the conventional systems, a reference to a data object always relates to a particular instance of the data object, i.e. to the data object at a specific state, and the state of the data object cannot be changed while a user's action is awaited. However, in team-based processing it must be possible for one user to change the state of a data object while another user is awaited to perform a required action on the data object. The conventional systems are limited to processing scenarios where the information included in a data object and references to the data object remain valid (unchanged) from the time the data object is assigned to a workflow state to the time actions are performed in the data object. Otherwise, if the data object changed between the time the user was notified and the time he/she actually performed the required action, the action may be inappropriate and/or performed on the wrong instance of data object.